home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000338_connolly@pixel.convex.com _Wed Nov 18 08:58:59 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA07730; Wed, 18 Nov 92 08:58:59 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA07574; Wed, 18 Nov 92 09:11:58 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA09383; Wed, 18 Nov 92 00:09:44 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA10572; Tue, 17 Nov 92 20:14:31 -0600
  10. Message-Id: <9211180214.AA10572@pixel.convex.com>
  11. To: marca@ncsa.uiuc.edu (Marc Andreessen)
  12. Cc: timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
  13. Subject: Re: 3D graphics? 
  14. In-Reply-To: Your message of "Tue, 17 Nov 92 19:29:52 PST."
  15.              <9211180329.AA05841@wintermute.ncsa.uiuc.edu> 
  16. Date: Tue, 17 Nov 92 20:14:31 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >(1) Has anyone done work wrt adding real data (in whatever format) to
  21. >    www?
  22.  
  23. No, but I think there's some stuff on gopher and WAIS servers that
  24. you might be able to get at.
  25.  
  26. >(2) Is there a consensus on supporting MIME in HTML and vice versa?
  27.  
  28. There's a growing consensus.
  29.  
  30. The strategy isn't to shoehorn MIME inside HTML, though we are
  31. shoehorning HTML inside MIME, i.e. there will soon be a text/html
  32. MIME content type.
  33.  
  34. The strategy is to treat the current data format as a special case of
  35. the more general MIME body part scheme.  Currently, www clients expect
  36. text/html or text/plain body parts, and it uses things like filename
  37. suffixes to tell the difference. If you point www at
  38.  
  39. ftp://ftp.ora.com/pub/davenport/Xhelp/Xhelp_Sept_11.ps
  40.  
  41. It will gladly fill your screen with unintelligible postscript code.
  42.  
  43. The strategy is that WWW clients will be able to negotiate various
  44. formats with servers, and the client will know what format the
  45. data is in before it comes over the wire. The other MIME types
  46. will be alternatives to text/html, not enclosures within it.
  47.  
  48. For protocols like FTP, we need to have type information in
  49. the links, like:
  50.  
  51. <a HREF="ftp://info.cern.ch/pub/www/NextBrowser.tiff"
  52.     type="image/x-tiff">The NeXT browser in action</a>
  53.  
  54. the the client would know better than to try to display the
  55. contents of the tiff file in a text window. The easiest thing
  56. to do is to pass it off to
  57.  
  58. % metamail -b -c "image/x-tiff" /tmp/www_ftp.4322
  59.  
  60. and let metamail to the rest.
  61.  
  62. For WAIS, the type information is in the protocol. For gopher, it
  63. mostly is. For HTTP, the client and the server are supposed to
  64. negotiate the format based on compute resources required for the
  65. conversion, network transmission time, distortion/loss of data,
  66. etc.
  67.  
  68. That's my two cents, anyway.
  69.  
  70. Dan
  71.